@bors delegate try

Unknown command "delegate". Run @bors help to see available commands.

Hmm, not sure about the exact syntax, but delegate itself should have been recognized, maybe not ported to the new bots yet? I'll let Jakub handle it.
For now

@bors try jobs=dist-aarch64-apple

@bors delegate=try

✌️ @sgasho, you can now perform try builds on this pull request!

You can now post @bors try to start a try build.

☀️ Try build successful (CI)
Build commit: a658070 (a65807068ca7fef2605b24756206b9e5dfa49bbd, parent: db1484bdee1cb065b322a5bd512b39c49dadc9e5)

☔ The latest upstream changes (presumably #150541) made this pull request unmergeable. Please resolve the merge conflicts.

@bors try jobs=dist-aarch64-apple

@bors try jobs=dist-aarch64-apple

@bors try jobs=dist-aarch64-apple

💔 Test for 2c9be7e failed: CI. Failed job:

• try - dist-aarch64-apple (web logs, enhanced plaintext logs)

@bors retry

❗ You can only retry pull requests that are approved and have a previously failed auto build.

I realized that we cannot use export-symbols immediately; we have to expand it to use it for dylib.
I'll make some extra commits, then create CI artifacts.

I have updated this branch because #150992 has been merged into main. I'll expand it so that it can be used for dylib.

@bors try jobs=dist-aarch64-apple

💔 Test for 094255a failed: CI

@bors try jobs=dist-aarch64-apple

☀️ Try build successful (CI)
Build commit: 6d0c1c7 (6d0c1c7f8aeee86ea677552367208f666f622c41, parent: bb8b30a5fce59f5d3d17a8f010601c59f0f19d79)

I verified that the simple autodiff code below works with llvm.link-shared=true.
Next, I'm trying to expand the export-symbols flag so that we can use autodiff on macOS with statically linked LLVM.

#![feature(autodiff)]
use std::autodiff::*;

// f(x) = x * x, f'(x) = 2.0 * x
// bar therefore returns (x * x, 2.0 * x)
#[autodiff_reverse(bar, Active, Active)]
fn foo(x: f32) -> f32 {
    x * x
}

fn main() {
    assert_eq!(bar(3.0, 1.0), (9.0, 6.0));
    assert_eq!(bar(4.0, 1.0), (16.0, 8.0));
}

Current stable rustc exports 436 llvm symbols.

nm -gU /Users/sgasho/.rustup/toolchains/stable-aarch64-apple-darwin/lib/librustc_driver-015fbde41a4573ae.dylib | grep -i "LLVM" | wc -l
     436

If we implement #151243, its result would be 40k

nm -gU ~/Downloads/rust-nightly-aarch64-apple-darwin\ 2/rustc/lib/librustc_driver-87e8ef082ced32c9.dylib | grep -i "LLVM" | wc -l
   43404

All symbols in rustc_driver would be 60k

nm -gU ~/Downloads/rust-nightly-aarch64-apple-darwin\ 2/rustc/lib/librustc_driver-87e8ef082ced32c9.dylib | wc -l 
   64141

Undefined symbols for libEnzyme

nm -u ~/Desktop/enz-ci/lib/libEnzyme-22.dylib | grep -i "LLVM" | wc -l
     860

I have not found the good solution to export only what libEnzyme needs in a reasonable way.
I'm going to explore it step by step, narrowing the symbols to export.
On the other hand, I don't have a strong opinion of whether we should limit what symbols to export, I mean, I don't know the critical problem of exporting 60k~ symbols in rustc_driver. I know it's not a clean way though.

So, for the first step, I implemented export-all-symbols and I'll see if it works fine. I think I could expand export-symbols but I did not have enough time to implement it today...

@bors try jobs=dist-aarch64-apple

☀️ Try build successful (CI)
Build commit: c2aef13 (c2aef135c60223aee3244fd33b97639eae6fca97, parent: 71e00273c0921e1bc850ae8cc4161fbb44cfa848)

"-Zexport-all-symbols" worked.
Next, I'm going to try expanding export-symbols. We have to set so many .a files to the flag, but we might be able to solve this problem programmatically.....I guess.

Revert export-all-symbols impl for now.

@Kobzol @bjorn3 Do you have any thoughts on which path to follow here?
We have
A) dynamic linking
B) static linking, exposing all LLVM symbols from rustc (see above for stats)
C) static linking, with @sgasho trying to further minimize the symbols we expose.

Since this is already our slowest runner, I was somewhat worried about doing any larger changes like using dynamic linking. However, the other two approaches also seem to have their downsides, B) exposes a lot more symbols (not sure how far that could affect startup time) and C) has more complexity and would need to be implemented.

We originally started on this journey in an attempt of not statically linking Enzyme into rustc, so we could make shipping it optional. I think either alternative above is an improvement over that solution, so I'd let you two choosee. Any preference?